home *** CD-ROM | disk | FTP | other *** search
-
- Douglas Little wrote:
-
- > We could manage a palette per texture if we dropped the shading effects, but I
- > don't think the loss of atmosphere is worth the gain in colours.
-
- > Couldn't we, as we are in TC, manage the doom
- > system with the palettes, along with 16 bit
- > textures that are algorythmically shaded? After
-
- I'm not quite sure where you are going with this...
-
- > all, the lighting effects are simple enough... Even
- > the anti-radiation suit, berserk and similar
- > effects are just "negative black-and-whitisation",
- > enhancement of the red or green, and so on. That
- > is, only effects that are very easy to do in a TC
- > mode.
-
- 'very easy' is a relative term. Very easy compared with bitplanes modes,
- but close to impossible in realtime in without the DSP (if you want it to look
- good) - and the DSP is already very busy working out vital coordinate & texel
- information at the drawing stage. The CPU can't hack disassembling a pixel into
- RGB / YUV before modification and reassembling back into 16-bit rgb. You would
- need at least a 68040 for that at any reasonable speed.
-
- Even a fast PC would choke on that! :)
-
- > Am I talking nonsense?
-
- No, but it's VERY optimistic to think in terms of realtime colour adjustment at
- the pixel level. The shading used to work this way on version 1.8 or thereabouts. It
- was based on a realtime additive/subtractive scheme when drawing rather than a scalar
- theme using precalculated tables (as it does now) - but there were complaints about
- colour bands in the floors. I expect the walls might have looked even worse. There's no
- way we can use a realtime scalar system for shading the pixels without the DSP and even
- then it's about 12-30 instructions per pixel - excluding the read/write over the bus for
- the original/final texel data. We are talking around half the speed we see just now at
- a rough guess, mostly due to bus activity.
-
- Doug.
-
-